System and method to provide real time transaction validation and billing via a communications network

ABSTRACT

A system and method for providing real-time validation to a content provider of a customer&#39;s request transmitted via a communications system for delivery of content by the content provider to the customer via a communications system. A request for validation of the customer from the content provider, the request including data identifying the customer, is dealt with by determining from the identifying data whether the customer is a subscriber and then immediately requesting acknowledgement by the customer of the customer&#39;s request for the delivery of the content. Upon receipt of an acknowledgement from the customer a validation of the customer&#39;s request is sent to the content provider.

FIELD OF THE INVENTION

The present invention relates to the billing and validation oftransactions carried out via a communications network, and inparticular, to the billing and validation of such transactions in whichcontent may be delivered immediately via the communications network.

BACKGROUND OF THE INVENTION

The development of electronic commerce has to date relied generally uponthe use of validation systems that predate the Internet and cellulartelephones capable of digital data communication. For example, thepurchase of software downloadable via the Internet has been possible forsome time, but it is normally carried out using charge accounts. Thecustomer selects software for purchase and provides a charge card numberand other information to the software vendor via a secure encryptedconnection. The software vendor then contacts the credit company by wayof a separate channel using a digital protocol, and requestsverification of the information that the customer provided. If all ofthe information is in order the credit company authorizes and guaranteesthe sale. Thus the vendor obtains validation from the credit company andallows the download to proceed.

Credit companies usually charge a percentage of the purchase price fortheir services. For this reason, the current systems for purchase ofcontent via the Internet or other communications networks are in generalnot well suited to small purchases (“micro-payments”) of, for example,less than a few dollars. An exception to this is the model used bytelephone carriers for providing services such as directory assistancefor a small charge and by the iMode cellular network system provided byNTT DoCoMo in Japan. In each case, the carrier itself either is thecontent provider (in the case of telephone carriers) or deals with thecontent providers (in the case of iMode) and provides the contentdirectly to the user. While the iMode business model works for smallamounts of data provided at low prices, it does not appear to be ofinterest to telephone carriers in North America, possibly due to theneed to deal with a multitude of content providers.

A need exists for a method and system for validation of requests bycustomers for electronic content that (1) does not involve thevalidation service provider in the handling of large amounts of datarepresenting the content and (2) is able to handle a variety of paymentmethods, including subscriptions, prepaid accounts, and micro-paymentsfor content in a cost efficient manner for a large number of contentproviders.

SUMMARY OF THE INVENTION

The inventive method and system provides real-time validation to acontent provider of a customer's request, transmitted via acommunications network, for delivery of content by the content providerto the customer, which delivery may be via the same communicationsnetwork or other means. The inventive method includes (1) receiving arequest for validation of a customer from the content provider, therequest including data identifying the customer, (2) determining fromthe identifying data whether the customer is a subscriber, and (3)verifying that the customer request for service is not fraudulent,through direct contact with the customer or other means.

“Real-time” herein shall mean in a time comparable or less than the timetypically needed for a merchant to obtain validation of a credit card ordebit card transaction.

The request for validation may include data identifying at least onecharacteristic of the content requested by the customer, such as thecharge to be paid by the customer for the content. If the customer'srequest is acknowledged and validation is sent to the content provider,then the charge to be paid is stored for later aggregation and billingto either the customer's account with the carrier of the communicationssystem, the customer's charge account, or the customer's prepaidaccount.

Further, the system can employ the use of digital signatures as part ofthe customer authorization of the transaction. The approval may be on atransaction originated by the content provider or on a transactionoriginated by the system. The digital signature of electronic documentsmay not require a payment transaction.

Customers may have temporary identification data assigned to them by thecommunications system. The temporary identification data could betranslated into a billing identity by the validation system so as tokeep the customer's identity secret.

Private or public key encryption methods may be used to verify thecustomer identity.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating the flow of data in a transactionvalidation and billing system embodying the present invention.

FIG. 2 is a flowchart of a transaction validation and billing systemembodying the present invention.

FIG. 3 is more detailed depiction of the software abstractions of atransaction validation and billing system embodying the presentinvention.

DETAILED DESCRIPTION

The overall flow of data in the real-time transaction validation andbilling system is illustrated in FIG. 1. A customer 10 has decided topurchase content from a content provider 12. The system provides atransaction validation server 14 and a database 16, which interact withcustomer 10 and content provider 12 to validate a customer's request forcontent 20. The server 14 also provides billing information to credit orprepaid service providers 18.

More specifically, the customer 10 sends a request for content 20 to thecontent provider 12 via a communications link 21. The content requestedmay be electronic, such as an audio or video file, a software program,or a key to unlock a file or program on a storage medium such as aCD-ROM. While the system is primarily addressed to the problem ofproviding real time validation of the delivery of electronic content, itmay also be used for the validation of transactions involving thephysical delivery of goods or the provision of services, particularlytransactions involving “micro-payments”. For example, the “content”might be an item from a vending machine. Hence, “content” herein shouldbe read widely to include anything that can be the subject of acommercial transaction. The delivery of content is indicated byreference numeral 32 in FIG. 1 and is shown as taking place via thecommunications link 21, but it should be kept in mind that the contentcould be delivered in some manner other than the communication link 21used by the customer 10 to make the request 20.

The content provider 12, upon receiving a request for content 20 fromthe customer 10, in turn sends a request for validation 22 to thetransaction validation server 14 via a second communications link 23,which may be the same or a different form of communication from thatused by the customer 10 to request the content. The validation request22 includes data identifying the customer 10 and may include other dataidentifying the content. The identifying data may be an identifierembedded in the validation request 22 that is unique to customer 10.Suitable applets, custom software or application plug-ins may berequired to facilitate the transmission of the appropriate identifier bythe content provider 12 to the transaction validation server 14. Thevalidation request 22 may also include a price to be charged for thecontent.

The transaction validation server 14, upon receipt of the validationrequest 22, sends a query 24 to the database 16 to obtain customer data25, including records of what arrangements, if any, the customer 10 hasmade to pay for the content requested. Such arrangements may includepurchase of a prepaid billing plan or subscription, arrangements withthe provider (“the carrier” herein) of the communications link 21 or anagreement to pay by a credit card account. The database 16 may alsoinclude purchase quantity or cost limits specified by the customer 10 inadvance. The database 16 may also include historical data regardingprevious validation requests and address data necessary for thetransaction validation server 14 to send an immediate acknowledgementrequest 26 to the customer 10.

The transaction validation server 14, assuming that the customer 10 isfound in the subscription database 16 and is in good standing, thenchecks whether it is necessary to send an acknowledgment request 26 tothe customer 10, as this requirement may be waived by some customers inpredefined circumstances, or to some third party. If such a request isnecessary the transaction validation server 14 sends the acknowledgmentrequest 26 to the customer 10, or the third party, via a thirdcommunications link 27, which may be the same as the communication link21 used to communicate the request for content 20. If the customer 10 orthird party confirms the request for content 20 by sending anacknowledgment 28 back to the transaction validation server 14, then thetransaction validation server 14 in turn sends a validation 30 to thecontent provider 12 over the second communication link 23. The contentprovider 12 then in turn transfers 32 the content to the customer 10. Asdiscussed above, transfer 32 could include physical delivery of thecontent as well as electronic delivery via a communications network.

Preferably, the transaction validation server 14 also provides forbilling the charges for each transfer of content 32 to the customer 10,although the content provider 12 could instead take care of the billingitself. A number of methods may be provided for doing so. For example,as shown in FIG. 1, the transaction validation server 14 may sendaggregated billing for content data 34 to a carrier, a charge cardsystem such as VISA™, or a prepaid billing system. Alternatively, thecustomer 10 may have prepaid for transfers of content 32. All threealternatives are represented by the block labeled with reference numeral18 in FIG. 1.

An advantage of the inventive method is that many small charges may beaggregated and billed at one time. A further advantage is that thetransaction validation server 14 does not handle the transfer of content32. The transaction validation server 14 does not necessarily need toknow what the content is, so long as the price to be charged isdeterminable and the customer 10 acknowledges the acknowledgment request26, as per the pre-arranged method. Not only does the transfer of thecontent 32 not place a strain on the transaction validation server 14,but also the privacy of the customer 10 and the content provider 12 ismaintained. In prior validation methods known to the inventors thecontent flows through a transaction server, requiring close involvementof the operator of the transaction server with the content provider.

A further advantage of the inventive system and method is that thecustomer 10 may not need to enter any identification or password whenrequesting delivery of content. For example, when communication link 21is a wireless Internet system, the customer 10 is identified by thewireless device used.

In the system described in relation to FIG. 1, to simplify thedescription it has been assumed that the person initiating the requestfor content 20 is the same person who has the responsibility for payingthe charges for the content. In most cases that person will be asubscriber to a carrier that makes use of the validation and billingsystem described herein. However, there is no reason that the personinitiating the request for content 20 must be a subscriber. Suppose thata subscriber's child is the customer 10 and is with the permission ofthe subscriber operating a cellular telephone with digital datacommunication capabilities. This situation is illustrated in FIG. 1A,which differs from FIG. 1 only in that the acknowledgement request 26 issent out by the transaction validation server 14 to the subscriber,indicated by reference numeral 11, rather than to the customer 10, andthe subscriber 11 replies with the acknowledgement 28, assuming that thesubscriber 11 authorizes the content transfer 32. The content provider12 and the transaction validation server 14 have no way of know whetherthe customer 10 and the subscriber 11 are the same person or not.

A high level flowchart of the process employed by an embodiment of thetransaction validation system of FIG. 1A that could be run on server 14to provide real time transaction validation and billing as describedabove is shown in FIG. 2. The process begins at block 50 by receipt bythe transaction validation server 14 of a request 22 from a contentprovider 12 for validation of a customer's request for content 20. Therequest for content will include some identification of the source ofthe request for content 20. For example, the identification might be theunique hardware identifier of a digital cellular telephone, which isautomatically sent whenever the cellular telephone is used. At block 52,the transaction validation server 14 verifies that the identificationincluded in the request for content 20 matches that of a subscriber 11.Note that matching at this stage does not mean that the request forcontent is valid and authorized by the subscriber 11 as the cellulartelephone could be stolen or the customer 10, who might not be thesubscriber, could be attempting to obtain content that the subscriber 11has not authorized. If there is no match at block 52, control passes toblock 64, at which the content provider 12 is informed of the denial ofthe validation request 22. If there is a match at block 52, thetransaction validation server 14 at block 54 checks to see if thesubscriber 11 has preauthorized the charge for the content requested. Ifthe subscriber 11 has not, the transaction validation server 14 at block56 sends an acknowledgement request 26 to the subscriber 11. At block58, if a response to the acknowledgement request 26 is received back inwhich acknowledgement is refused, or after some predetermined timelimit, control is transferred to block 64 at which the content provider12 is informed of the denial of the validation request 22. If thesubscriber 11 acknowledges the request for content 20 within the timelimit by returning an acknowledgement 28, then control is transferred toblock 60 at which the transaction validation server 14 sends avalidation 30 to the content provider 12. If the subscriber 11 was foundat block 54 to have preauthorized the charge for the content requested,then control also passes to block 60 at which the transaction validationserver 14 sends a validation 30 to the content provider 12. Followingexecution of block 60, control passes to block 62 at which the chargefor the content requested is added to an aggregate of charges for thesubscriber 11. Finally, the transaction validation process ends at block68 following either the execution of block 62 or block 64.

FIG. 3 shows in more detail the software abstractions of an exemplaryreal-time validation and billing system, collectively referred to byreference numeral 100, which could implement core functions of thetransaction validation server 14 and database 16 and is the presentlypreferred embodiment of a real-time validation and billing system. Ineffect, FIG. 3 is representation of how the system shown in simplifiedform in FIG. 1 could be implemented. Each abstraction represents aprocess running on one or more computers or a database or portion of adatabase resident on one or more computers. For example, each databaseabstraction may represent a table or a set of tables of a singledatabase structure and each process may be part of a single programrunning on a single computer.

In FIG. 3, communication between a customer 110 and the content provider112 is assumed to be via a communications system 114. The communicationssystem 114 could be the Internet or a service provided by a carrier. Forthe purposes of this example, it is assumed that the customer 110 is asubscriber to a wireless communications system 114 operated by acarrier. The carrier's data processing facilities are represented inFIG. 3 by block 116 and include at least the capability of providingupdated lists of the subscribers to the communications system 114.Communication between the content provider 112 and the system 100 is viaa second communication system 115, which should preferably be a privatenetwork for security. Communication between the system 100 and thecustomer 110 is via a third communication system 117, which may utilizesystem 114. For example, such communication may involve “tunneling” backthrough communications system 115 and communication system 114.

To further clarify the flow of data in the transaction validationsystem, the transaction validation server 14 in FIG. 1 is represented inFIG. 3 as several processes: a real-time billing handler 118; asubscriber handler 120; a rating services handler 122; a revenuedistributor 124; and a marketing data collector 126. Likewise, thedatabase 16 of FIG. 1 is represented as several databases in FIG. 3:

-   -   (1) a subscriber database 128, containing data on each        subscriber, which may include identification of a rate plan        selected by the subscriber, a desired currency for charges to        the subscriber, and directions as to the conditions under which        the subscriber will be asked to confirm transactions;    -   (2) a rate plans database 130, containing definitions of rate        plans that may be selected by subscribers and may include        methods for calculating the price to be charged for the content;    -   (3) a currency database 132, containing current exchange rates;    -   (4) a purchase history database 134, containing records of all        transactions completed by the subscribers and content providers;        and    -   (5) a revenue log database 136, containing a record of revenue        attributed to the transaction validation service.

Block 18 of FIG. 1, which represents the carrier, charge card company,or prepaid billing company has been expanded in FIG. 3 into two blocks:the carrier 116 and a financial institution 140, which may be a walletor credit company, prepaid company, or a bank.

Data flows in the system 100 are now described. Upon receipt of arequest for content from the customer 110 via communication system 114,the content provider 112 sends a query via communication system 115containing data identifying the customer 110 and the content requestedto the real-time billing handler 118 asking for validation of thecustomer's request for content. The real-time billing handler 118creates a transaction object containing at least the data received fromthe content provider 112 and in turn sends a query to the subscriberhandler 120 referencing the transaction object.

Using the customer identification data in the transaction object, thesubscriber handler 120 queries the subscriber database 128 to determinewhether there is a current subscriber whose customer identification datamatches that received by the real-time billing handler 118 from thecontent provider 112. If no match is found in the subscriber database128, the subscriber handler 120 checks the carrier's data processingsystem 116 to determine whether the customer 110 is a currentsubscriber. This determination may optionally be done even if thecustomer 110 is found in the subscriber database 128 or may be done inlieu of checking subscriber database 128.

If the customer 110 is determined to be a subscriber to thecommunication system 114 provided by the carrier 116, then thesubscriber handler 120 will ask the rating services handler 122 for theprice to be charged for the content requested by the customer 110. Therating services handler 122, using the data contained in the transactionobject, queries the subscriber database 128, to determine which rateplan should be applied to the transaction, the rate plan database 130 todetermine a price to be charged for the requested content based upon therate plan to be applied and the identification of the content, and thecurrency database 132 for the proper exchange rate, if any, to beapplied to the price so as to calculate the price in the preferredcurrency of the customer 110. The rating services handler 122 reportsthe price for the transaction back to the subscriber handler 120.

The subscriber handler 120 then, if the data found in the subscriberdatabase 128 indicates that the price is to be charged to the customer'saccount with the financial institution 140, may seek preauthorizationfrom the financial institution 140. If preauthorization is refused, thesubscriber handler 120 reports back to the real-time billing handler118, which in turn reports to the content provider 112 and closes thetransaction.

If no preauthorization is required or if preauthorization is given bythe financial institution 140, the subscriber handler 120 communicatesthe final price to the customer 110 as part of an acknowledgment requestsent via communications system 117 and then waits for an acknowledgmentfrom the customer 10. If the subscription database 128 contains specialinstructions regarding acknowledgment, then the acknowledgment requestwill instead be directed to a third party or the transactionautomatically confirmed or rejected based upon customer-defined pricethresholds. When a decision is reached, the subscriber handler 120responds accordingly to the real-time billing handler 118. The real-timebilling handler 118 then informs the content provider 112 as to thedecision (shown in FIG. 1 as a validation 30).

If the content provider 110 receives validation from the real-timebilling handler 118, then the content provider 110 commences providingthe content. When the content provider has finished providing thecontent, it sends a service complete message to the real-time billinghandler 118. This informs the real-time billing handler 118 to close thetransaction and report to the rating services handler 122 that thetransaction is closed. If the content is to be provided over an extendedperiod in response to separate requests for content from the customer110, e.g., the content is a subscription to a service that providesupdated information for a specified time period for a fixed total fee,then the transaction is kept open and on receipt of validation requestsfrom the content provider 112, the billing handler 118 may only ask thesubscriber handler 120 to confirm that the customer 110 remains in thesubscriber database 128. No acknowledgment may be needed from thecustomer 110.

When a transaction is finally completed by the receipt of a servicecomplete message, the billing handler 118 notifies the rating serviceshandler 122, which in turn closes transaction object and the passes dataregarding the transaction on to a revenue distributor handler 124. Thedata passed to the revenue distributor handler 124 may include data fromthe rate plans database 130, the currency database 132, and the purchasehistory database 134 in addition to the details of the transaction justclosed. The revenue distributor handler 124 stores the details of thejust closed transaction in the purchase history database 134 anddetermines which method was chosen by the customer 110 for payment basedon information from the rating services handler 122. Depending upon thepayment method chosen, the revenue distributor handler 124 sends theappropriate data on to the financial institution 140 or the carrier 116.Finally, a log is made of the revenue to be attributed towards theoperation of the system 100 by storing appropriate data in revenue logdatabase 136.

Subscribers may be provided with means for reviewing transactions andoptions such as redirecting acknowledgment requests to a device otherthan that from which a request for content 20 originated. For example,the subscriber may be a parent and the customer 110 at a given time maybe the parent's child. In that case, the subscriber may wish to haveacknowledgment requests 20 sent to the subscriber rather than thecustomer 110, if the transaction involves more than a preset cost orcontent other than preset content. Such data may be stored in thesubscriber database 128 for use by the subscriber handler 120.

Optionally, the marketing data collector handler 126 may extract datafrom the purchase history database 134 to aggregate and summarize datafor the carrier 116 or possibly other planning uses. Further, therevenue distributor handler 124 can query the purchase history database134 for statistics, reports, or dispute resolution. For example,disputes involving micro-payments may be handled automatically byreversing charges to a customer's account unless the purchase historydatabase 134 contains evidence that suggest abuse of the system by thecustomer.

The identity of the customer 110 may be kept secret from the contentprovider 112 by use of temporary identification data assigned by thecarrier 116 and used by the customer 110 to communicate with the contentprovider 112 and receive content via the communications system 114, ifthe content is to be provided via that system. Only the temporaryidentification data would be sent to the content provider 112 by thecustomer 110 during the request for content. The correspondence betweenthe temporary identification data and the identity of the customer 110would be available to the subscriber handler 120 for validation andbilling purposes, but the identity of the customer 110 would not beprovided to the content provider 112. The temporary identification datamay be set up as part of the subscription process by the carrier 116 andmay be changed periodically thereafter or may be assigned dynamically bythe carrier 116 each time the customer 110 uses the device. Further,digital signatures may be used in all communications between thecustomer 110, the content provider 112 and the system 100. As well,private or public key encryption methods may be used to protect andverify customer identity.

The transaction validation and billing system and method described abovemay be implemented in a variety of ways. Those skilled in the art willunderstand that the above description enables the implementation of theinvention using other combinations of computers and communicationnetworks.

1. A computer method for providing real-time validation to a contentprovider of a customer's request transmitted via a first communicationslink for delivery of content by the content provider to the customer andfor providing aggregated billing in a transaction, the methodcomprising: maintaining a subscriber database containing dataidentifying subscribers to a wireless communications system operated bya carrier; receiving at a transaction validation server a request fromthe content provider for validation of the customer's request, thecontent provider's request including data identifying the customer anddata identifying the content including a charge for the content;querying the subscriber database to determine whether the dataidentifying the customer matches that corresponding data for asubscriber and to determine a rate plan to be applied to thetransaction; if the data identifying the customer matches thatcorresponding data for a subscriber, then the transaction validationserver determining the price to be charged for the content based uponthe rate plan to be applied and the data identifying the content; thetransaction validation server communicating directly with the subscribervia a second communications link and requesting acknowledgment from thesubscriber of the request for the delivery of the content; and uponreceipt of an acknowledgment from the subscriber at the transactionvalidation server, the transaction validation server sending to thecontent provider a validation of the customer's request and adding theprice to be charged for the content to an aggregate of charges for thesubscriber.
 2. The method of claim 1, wherein the first and secondcommunications link use a common communication system.
 3. The method ofclaim 2, wherein the common communication system is a wireless system.4. The method of claim 1, further comprising the step of communicatingthe aggregate of charges for the subscriber to a carrier or a financialinstitution.
 5. The method of claim 1, further comprising the step ofcommunicating the aggregate of charges for the subscriber to a carrier.6. The method of claim 1, additionally comprising billing the aggregateof charges to the subscriber.
 7. The method of claim 1, wherein thecustomer and the subscriber are different persons.
 8. A computer systemfor providing real-time validation to a content provider of a customer'srequest transmitted via a first communications link for delivery ofcontent by the content provider to the customer and for providingaggregated billing in a transaction, the system comprising: a subscriberdatabase server containing data identifying subscribers to a wirelesscommunications system operated by a carrier; a first communicationinterface for sending data to and receiving data from the contentprovider via a second communications link; a second communicationinterface for sending data to and receiving data from the subscribersvia a third communications link; and a processor for processing datareceived by the first communication interface requesting validation ofthe customer's request, the request received including customeridentification data and content identification data including a chargefor the content, querying the subscriber database to determine whetherthe customer identification data matches corresponding data for asubscriber and to determine a rate plan to be applied to thetransaction; if the customer identification data matches correspondingdata for a subscriber, determining the price to be charged for thecontent based, upon the rate plan to be applied and the contentidentification data; causing the second communication interface to senddata directly to the subscriber requesting acknowledgment from thesubscriber of the request for the delivery of the content, and uponreceipt of an acknowledgment by the second communication interface fromthe subscriber, causing the first communication interface to send to thecontent provider a validation of the customer's request and adding theprice to be charged for the content to an aggregate of charges for thesubscriber.
 9. The system of claim 8, wherein the processor communicatesthe aggregate of charges for the subscriber to a carrier or a financialinstitution.
 10. The system of claim 8, wherein the processorcommunicates the aggregate of charges for the subscriber to a carrier.11. The system of claim 8, wherein the processor bills the aggregate ofcharges to the subscriber.
 12. The system of claim 8, wherein thecustomer and the subscriber are different persons.
 13. The method asclaimed in claim 1, wherein said acknowledgement comprises an acceptanceof a charge by the subscriber.
 14. The system as claimed in claim 8,wherein said acknowledgement comprises an acceptance of a charge by thesubscriber.
 15. The method as claimed in claim 4, wherein the financialinstitution comprises a charge card system or prepaid billing system.16. The system as claimed in claim 9, wherein the financial institutioncomprises a charge card system or prepaid billing system.
 17. The methodas claimed in claim 1, wherein the data identifying the customer istemporary identification data assigned by a carrier.
 18. The system asclaimed in claim 8, wherein the customer identification data istemporary identification data assigned by a carrier.
 19. The method asclaimed in claim 1, wherein determining the price to be charged for thecontent is further based upon a currency exchange rate to be applied tothe price.
 20. The system as claimed in claim 8, wherein determining theprice to be charged for the content is further based upon a currencyexchange rate to be applied to the price.
 21. The method as claimed inclaim 1, wherein the data identifying the customer includes anidentification of the wireless device used by the customer.
 22. Thesystem as claimed in claim 8, wherein the customer identification dataincludes an identification of the wireless device used by the customer.